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REMARKS 

Reconsideration of the pending application is respectfully requested on the 
basis of the following particulars. 

L In the specification 

The specification is amended, as shown in the foregoing AMENDMENT TO 
THE SPECIFICATION, to eliminate reference to the claims. It is respectfully 
submitted that no new matter is added, as the changes simply correct minor 
informalities. 

Entry of the AMENDMENT TO THE SPECIFICATION is respectfully 
requested in the next Office communication. 

2< In the claims 

As shown in the foregoing LIST OF CURRENT CLAIMS, the claims have 
been amended to more clearly point out the subject matter for which protection is 
sought. 

Claim 1 is amended to incorporate the features of previously presented claims 
2, 6, and 13. It is respectfully submitted that no new matter is added, and no new 
issues are raised, since the changes merely merge the subject matter of previously 
presented claims. 

Claims 2, 6, and 13 are canceled and the subject matter thereof added to 
amended claim 1 . 

Claims 7, 18, 20, and 21 are canceled. 

Claims 10 and 19 remain canceled. 

Claims 3-5, 8, 9, 11, 12, and 14-17 are left unchanged. 

Entry of the LIST OF CURRENT CLAIMS is respectfully requested in the 
next Office communication. 
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3 - Rejection of claims 1-9, 11-18. 20 and 21 under 35 U.S.C. § 102(b) as being 
anticipated by U.S. publication no, 2002/0093856 (Baentsch) 

Reconsideration of this rejection is respectfully requested, in view of the 
amendments to claim 1 and the cancelation of claims 18, 20, and 21, and on the basis 
that the Baentsch publication fails to disclose each and every recited feature of 
amended claim 1. The remaining claims depend from claim 1, and are therefore 
patentable as containing all of the recited features of claim 1, as well as for their 
respective recited features. 

By way of review, amended claim 1 includes the features of previously 
dependent claims 2, 6, and 13. In particular, amended claim 1 requires a smart card 
chip, comprising a nonvolatile system memory, a Java Card Virtual Machine 
implemented in the nonvolatile system memory, a nonvolatile application memory, a 
volatile working memory and a variables memory area reserved for global variables, 
the variables memory area being reserved in the volatile working memory. The 
variables memory area is reserved by a Java package implemented in the smart card 
chip 

Further, the variables memory area is accessible only by programs stored in 
the system memory and the programs may access the variables memory area that can 
link to the variables memory area, and an export component of the Java package 
containing the link information required for linking to the reserved variables memory 
area is not implemented in the smart card chip. 

In other words, a smart card chip with a Java Card Virtual Machine and a 
memory area reserved for global variables is provided such that access to the global 
variables is simple, fast, and gentle on the chip (specification paragraph [0024]). 

According to amended claim 1, a memory area for global variables is reserved 
in RAM by a specific Java package implemented in the chip, thus providing fast 
access to the global variables, which is also gentle on the chip (specification 
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paragraphs [0024], [0045], [0046]). Due to the fact that the variable memories area is 
reserved by access information directed directly to the working memory, i.e. the 
RAM, simple access thereto is also ensured (claim 5; specification paragraph [0046]). 

Amended claim 1 also indicates that only programs stored in the system 
memory can access the variables memory area. This is accomplished, as recited in 
amended claim 1, by allowing the programs to access the variables memory area that 
can link to the variables memory area, and an export component of the Java package 
containing the link information required for linking to the reserved variables memory 
area is not implemented in the smart card chip (specification paragraphs [0047], 
[0048]). In other words, a postloaded package implemented in EEPROM cannot 
access the variables memory 18 reserved in RAM, while a preloaded package 
implemented in ROM can use the reserved variables memory area of the RAM 
package (specification paragraphs [0047], [0048]). 

As a further clarification of these features, according to amended claim 1, the 
variables memory area is reserved by a Java package that is implemented in the smart 
card chip, and it is the sole function of this Java package to reserve memory in RAM 
(specification paragraph [0032]). No substantial changes to the existing Java Card 
Virtual Machine architecture appear to be necessary to incorporate the Java package 
recited in amended claim 1 (specification paragraph [0036]). 

According to Java Card technology, a program, represented by a Java package, 
may both provide and access services of another program. In order to technically 
permit such access, one program accessing the service of another program has to have 
the possibility to link to the other program. The respective link information is also 
called export information (specification paragraphs [0009]-[0012]). 

According to amended claim 1, since the global variables memory area is 
reserved by the recited Java package, this package may be interpreted to offer the 
service of providing memory in RAM to other programs. In order to access this 
service, the other program has to link to the recited Java package. This, however, is 
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only possible if the other program has access to the export information of the recited 
Java package* 

According to amended claim 1, this link (or export information) is not 
implemented in the smart card chip. Consequently, only those programs having 
alternative access to this link information can link to the variables memory area. 

At least the system programs, generally implemented by the issuer of the 
smart card, and perhaps some other applets called pre-issuance packages also 
provided by the card issuer, which are linked before the completion of the smart card 
by means of an "off-card linker" have access to the link information stored in a 
certain filed, called export file (specification paragraphs [0013], [0015]). This export 
file is not publically accessible. 

Applets or programs that are only installed after completion of the smart card, 
for example, by certain service providers, are linked on the card by means of an on- 
card linker and do not have access to the link information of the recited Java package, 
since this link information is, for example, as part of a secret export file, not 
implemented on the chip. Consequently, these applets or programs do not have 
access to the recited variables memory area (specification paragraphs [0038], [0049]). 

These features are recited in amended claim 1, and are further defined, for 
example, in dependent claims 3, 8, and 9. 

Turning to the Baentsch publication, a technique for language verification of a 
Java card CAP file is provided (abstract). The Baentsch publication discloses (in 
paragraph [0009]) a standard smart card having RAM, EEPROM, and ROM memory 
areas (of the type also described in paragraph [0003] of the pending specification). 
As described in detail in the pending specification, paragraphs [0018], [0021], in 
present Java card implementations, only local variables are allocated in RAM, while 
static (i.e. global) variables are implemented in EEPROM. 
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The Baentsch publication is silent as to the allocations of local and static 
variables. The assertion on page 2 of the Office action that static variables are stored 
in RAM finds no basis in the Baentsch publication, and further, since RAM is 
volatile, it is respectfully submitted that a person having ordinary skill in the art 
would store any static variables of the Baentsch publication in the non-volatile 
EEPROM or ROM, and not in the volatile RAM, so that the static (global) variables 
would not be lost when power is interrupted to the RAM. 

Further, the assertion on page 2 of the Office action that the claimed "variables 
memory area" corresponds to any area in RAM that stores variables or parameters 
misses the fact that the recited variables memory according to amended claim 1 is 
reserved by a Java package implemented in the smart card chip. The Baentsch 
publication is simply silent as to this feature of amended claim 1 . 

Additionally, the Baentsch publication is further silent as to which programs 
may access the "any area in RAM that stores variables or parameters" (identified as 
corresponding to the recited variables memory area of amended claim 1) and which 
programs cannot access the "any area in RAM that stores variables or parameters." 
As discussed above, amended claim 1 specifically defines which programs on the chip 
may gain access to the recited variables memory area, and which programs may not 
access the recited variables memory area, and provides the technical mechanism 
(linking using export component) for doing so. 

There is simply no disclosure in the Baentsch publication of these features of 
amended claim 1 > 

Accordingly, in view of the above discussion, it is submitted that the Baentsch 
publication fails to disclose every feature of amended claim 1, and withdrawal of this 
rejection is respectfully requested. 

As mentioned above, applicants submit that independent claim 1 is patentable 
and therefore, claims 3-5, 8, 9, 1 I, 12, and 14-17, which depend from claim 1, are also 
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considered to be patentable as containing all of the elements of claim 1, as well as for 
their respective recited features. 

4 > Rejection of claims 1-9, 1 LJJL 20 and 21 under 35 UJS.C. § 102(b) as being 
anticipated by "Proceedings of ACM Sigplan" (Shaylor) 

Reconsideration of this rejection is respectfully requested, in view of the 
amendments to claim 1 and the cancelation of claims 18, 20, and 21, and on the basis 
that the Shaylor publication fails to disclose each and every recited feature of 
amended claim 1. The remaining claims depend from claim 1, and are therefore 
patentable as containing all of the recited features of claim 1, as well as for their 
respective recited features. 

The features of amended claim 1 are discussed above in detail. 

Turning to the Shaylor publication, a Java virtual machine architecture for 
very small devices, such as smart cards which may have no more than 8KB of RAM, 
32 KB of non- volatile memory (EEPROM), and 160KB of ROM. 

While the Shaylor publication appears to disclose the mutable state of static 
variables stored in RAM, there is no disclosure in the Shaylor publication of how the 
RAM memory area is reserved for such variables, what programs have the ability 
and/or permission to access the reserved RAM area, and by what mechanism this 
access is provided or prevented, all of which are specifically recited in detail by 
amended claim 1, as discussed above. 

Since the Shaylor publication is silent as to all of these features, a person 
having ordinary skill in the art would first consult standard specifications, such as the 
Java Card Runtime Environment Specification (hereafter, "the Specification"), 
Version 2.2 J (available at http://java.sun.com/javacard/specs, html) in order to answer 
the above questions of how the RAM memory area is reserved for such variables, 
what programs have the ability and/or permission to access the reserved RAM area, 
and by what mechanism this access is provided or prevented. 
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As regards the basic question concerning the mere possibility of providing 
transient memory for global variables, the Specification (Chapter 5, page 23) indicates 
that Java Card does not support the keyword "transient.*' According to Java Card 
technology, transient objects may be reserved in the form of arrays. An array, under 
Java, represents a dynamically constructed object including a header and a number of 
fields of the same type. Such a type may represent a certain variable or again another 
array. That is, an array is necessarily embodied by a rather complex data structure 
including a large amount of administrative information including the header. A 
person having ordinary skill in the art, trying to reserve a variables memory area in 
RAM, would therefore use Java arrays for the purpose of providing transient memory. 
However, working with Java arrays appears to be much more complicated and 
consumes more resources than providing access to RAM by information being 
directly directed to RAM. 

Other than the above method of providing transient memory, which itself is 
not specifically described in the Shaylor publication, there is no further discussion of 
how to reserve a variables memory area in the volatile working memory by a Java 
package implemented on the smart card chip, as is required by amended claim L In 
fact, since in general, RAM memory management is a task of the operating system, 
integrating the possibility of reserving global variables in RAM of the Shaylor 
publication according to amended claim 1 would require a redesign of the operating 
system of the Shaylor publication. 

Further, there is no discussion in the Shaylor publication as to which programs 
may access the static variables in RAM and which programs cannot access the static 
variables in RAM, As discussed in detail above, amended claim 1 specifically defines 
which programs on the chip may gain access to the recited variables memory area, 
and which programs may not access the recited variables memory area, and provides 
the technical mechanism (linking using export component) for doing so. 
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There is simply no disclosure in the Shaylor publication of these features of 
amended claim 1 . 

Accordingly, in view of the above discussion, it is submitted that the Shaylor 
publication fails to disclose every feature of amended claim 1, and withdrawal of this 
rejection is respectfully requested. 

As mentioned above, applicants submit that independent claim 1 is patentable 
and therefore, claims 3-5, 8, 9, 1 1, 12, and 14-17, which depend from claim 1, are also 
considered to be patentable as containing all of the elements of claim 1, as well as for 
their respective recited features. 

5. Conclusion 

As a result of the amendment to the claims, and further in view of the 
foregoing remarks, it is respectfully submitted that the application is in condition for 
allowance. Accordingly, it is respectfully requested that every pending claim in the 
present application be allowed and the application be passed to issue. 

Please charge any additional fees required or credit any overpayments in 
connection with this paper to Deposit Account No. 02-0200. 

If any issues remain that may be resolved by a telephone or facsimile 
communication with the applicants' attorney, the examiner is invited to contact the 
undersigned at the numbers shown below. 



BACON & THOMAS, PLLC 
625 Slaters Lane, Fourth Floor 
Alexandria, Virginia 22314-1 176 
Phone: (703) 683-0500 
Facsimile: (703)683-1080 



/Justin J. Cassell/ 



Respectfully submitted, 



Date: December 8, 2009 



JUSTIN J. CASSELL 
Attorney for Applicants 
Registration No. 46,205 
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